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TACTICAL  ENVIRONMENTAL  DATA  SERVICES  (TEDSERVICES) 
POST  FBE-K  TECHNICAL  EXECUTION  REPORT 


INTRODUCTION 

This  report  reviews  the  technical  execution  of  the  Tactical  Environmental  Data  Services 
(TEDServices)  in  the  context  of  Fleet  Battle  Experiment  -  Kilo  (FBE-K).  The  report  includes  a 
comprehensive  description  of  TEDServices  features  executed  in  FBE-K.  Also  detailed  are  high-level 
TEDServices  concepts  and  software  components  as  well  as  operational  concepts  and  specific  data  flow 
scenarios. 

TEDServices  extends  the  Tactical  Environmental  Data  Server  (TEDS)  into  the  era  of  Net  Centric 
Warfare,  Sea  Power-21,  FORCEnet,  TaskForce  Web,  and  the  Navy  Enterprise  Portal  (NEP).  It  does  so 
by  means  of  a  new  Web-based  Service  architecture  and  the  Oceanographer  of  the  Navy’s  (N096) 
Operational  Concept  2002.  TEDServices  provides  a  Data-Oriented  Service  that  supports  the  management 
and  bi-directional  transport  of  meteorological,  oceanographic  and  environmental  information.  TEDS’ 
original  Relational  Database  Management  System  (RDBMS)  architecture  has  been  replaced  with  a 
lightweight,  forward-deployed  data  cache.  This  data  cache  offers  Warfighters,  Meteorology  and 
Oceanography  (MetOc)  professionals,  tactical  decision  aids  (TDAs)/applications  and  weapons  systems 
immediate  access  to  the  Virtual  Natural  Environment  (VNE),  a  4-dimensional  representation  of  the  User 
defined  battle-space  environment.  TEDServices  Clients  use  a  MetOc  data  order  process  to  subscribe  to 
relevant  data.  During  development,  the  design  tenets  of  TEDServices  included:  Data  Transport  (to 
reduce  bandwidth  use),  Data  Management  (to  simplify  data  ordering  and  forwarded  deployed  data 
administration),  Data  Representation  (implementation  of  a  unified  Geospatial  and  Time  Coordinate 
Process),  and  DoD  Joint  Interoperability  (supporting  standards  defined  by  the  Joint  MetOc 
Interoperability  Board). 

TEDServices  was  designed  to  enable  the  realization  of  the  Oceanographer  of  the  Navy’s 
Operation  Concept  (N096  OpCon).  Under  this  OpCon,  MetOc  Production  Centers,  Centers  of  Expertise, 
and  Domain  Authorities  deliver  authenticated  data  and  products  in  the  form  of  the  “MetOc  Answer”  to 
Warfighters  based  on  their  unique,  relevant,  operational  needs.  TEDServices  supports  this  operational 
concept  through  data  brokering  services,  data  ordering  processes,  an  application  programmer’s  interface 
and  an  efficient,  scaleable  common  data  transport  format. 

TEDServices  serves  as  the  primary  Fleet  repository  and  source  of  Meteorology  and 
Oceanography  (MetOc)  data.  TEDServices  provides  data  for  numerous  applications  including  the  Naval 
Integrated  Tactical  Environmental  Subsystem  II  Object-Oriented  Re-design  (NITES-II  OOR)  software 
series,  the  Common  Undersea  Picture  (CUP),  a  variety  of  TDAs,  and  any  other  application  that  requires 
access  to  up-to-date,  relevant  MetOc  and  environmental  data. 

TEDServices  fills  a  critical  DoD  requirement  for  standardized  MetOc  databases  and  extraction 
routines.  As  the  DoD  continues  to  move  into  the  network  centric  warfare  philosophy  of  the  21st  century, 
this  state-of-the-art  system  provides  weapons  systems,  warfighting  TDAs,  and  the  MetOc  professional 
with  a  common  geospatial  and  temporal  information  source  and  forward-deployed  assets.  TEDServices 
also  provides  a  data  path  back  to  Production  Centers,  Domain  Authorities,  and  Centers  of  Expertise  for 
on-scene  remote  observations  of  various  MetOc  data  elements.  For  the  first  time,  complete  collaborative 
planning  can  be  conducted  with  the  satisfaction  of  knowing  that  all  participants  are  using  the  same 
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datasets.  This  fully  upgradeable,  scaleable,  plug-and-play  architecture  is  the  culmination  of  years  of 
intensive  research  and  development  by  numerous  government  scientists  at  the  Naval  Research  Laboratory 
(NRL),  the  Naval  Undersea  Warfare  Center  (NUWC),  and  civilian  contractors. 

TEDServices  is  configured  to  support  four  conceptual  components  for  the  bi-directional  flow  of 
data.  These  components,  illustrated  in  Figure  1,  are  defined  by  the  N096  OpCon  (as  modified  by  the 
FBE-K  Concept  of  Operation  -  CONOP): 

1.  Production  Center  (PC).  This  component  produces  Numerical  Weather  &  Ocean  Prediction 
(NW&OP)  data  by  assimilating  global  In-Situ  data.  Examples  of  production  centers  include 
FNMOC,  NAVO,  AFWA  and  other  Allied  organizations. 

2.  Domain  Authority  (DA).  The  Domain  Authority  uses  NW&OP  within  an  expert  knowledge 
context  to  derive  the  global  “MetOc  Answer”  that  is  populated  within  its  VNE.  A  DA  can  be  co¬ 
located  within  a  Production  Center.  Defined  domains  include  the  following: 

•  Space 

•  Atmosphere 

•  Ocean  Surface 

•  Water  Column 

•  Ocean  Bottom 

•  Littoral 

•  Terrain 

3.  Center  of  Expertise  (CoE).  The  Center  of  Expertise  is  the  subject  matter  expert  (SME)  for 
MetOc  effect  on  missions  (Strike,  Under  Sea  Warfare,  Special  Operations  Forces,  etc).  The  CoE 
uses  data  from  the  Domain  Authority  VNEs,  as  well  as  non-MetOc  Auxiliary  data  sources,  to 
refine  the  Domain  Authority  MetOc  answer  and  produce  specific  data  parameters  and  products. 
CoEs  may  be  defined  for  either  a  tactical  focus  or  tactical  area  of  interest  (AOI)  and  can  be  co¬ 
located  within  a  Production  Center  or  Domain  Authority. 

4.  Remote  User  (RU).  A  Remote  User  can  be  an  ashore,  afloat  or  mobile  consumer  of  MetOc 
Answers  and/or  CoE  Products.  A  RU  is  represented  by  the  Warfighter,  Weapons  System,  or 
MetOc  Professional.  The  RU  orders  data  from  the  DA  VNE  and  the  CoE  Products  DataStore. 
Received  data  and  products  are  stored  in  a  Local  VNE  or  DataStore.  An  RU  can  be  co-located 
within  a  Production  Center,  Domain  Authority,  or  Center  of  Expertise. 

5.  Rapid  Environmental  Assessment  (REA).  The  REA  component  provides  assimilation  of 
Through-the-Sensor  (TTS)  In-Situ  data  to  update  key  parameters  in  the  Local  VNE.  In-Situ  data 
is  also  passed  back  to  Production  Centers  for  incorporation  into  future  model  runs. 
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Fig.  1  -  N096  OpCon  conceptual  components 


TEDSERVICES  TECHNOLOGY 
Services  and  Interfaces 

All  of  the  previously  described  N096  OpCon  conceptual  components  house  or  use  TEDServices 
software  technologies  to  facilitate  the  local  representation,  and  bi-directional  transport  of  data.  Within 
the  TEDServices  dialect,  these  technologies  are  defined  as  Technology  Services  and  Interfaces.  Services 
are  embodied  within  a  TEDServices  GateWay,  while  Interfaces  are  defined  as: 

•  The  TEDServices  Data  Browser,  which  can  be  invoked  through  a  web  browser. 

•  The  TEDServices  Application  Program  Interface  (API),  which  provides  methods  for 
subscribing  to,  as  well  as  querying  for  and  extracting,  data  and  products. 

•  The  TEDServices  Data  Ordering  Client,  which  is  a  Java-based  Graphical  User  Interface 
providing  support  to  legacy  systems. 


TEDServices  GateWay 

The  TEDServices  GateWay  is  a  scaleable,  platform  independent,  Java-based  software  process 
that  resides  on  a  web  server,  implemented  in  a  many-to-many  network  topology  paradigm.  The 
TEDServices  GateWay  facilitates  the  communications  between  users/applications  and  multiple  data 
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sources/formats.  It  supports  bi-directional  communications  (i.e.  data  requests  to/from  PCs,  CoEs,  and 
Domain  Authorities)  and  the  transport  of  In-Situ  observations.  TEDServices  GateWays  communicate 
within  the  topology  using  a  “publish  and  subscribe”  paradigm  that  ensures  the  delivery  of  relevant 
forward  deployed  data  to  the  end-user. 

There  is  ideally  one  TEDServices  GateWay  per  platform  or  location.  This  TEDServices 
GateWay  serves  all  users  and  applications  at  that  platform  or  location.  This  obviates  the  need  for  multiple 
reach  backs  for  the  same  data  by  multiple  users.  Obviating  this  type  of  reach  back  serves  to  reduce 
bandwidth  usage. 

The  GateWay  supports  NIPRNET  and  SIPRNET  using  a  standard  http(s)  communication 
protocol  over  port  80  (443).  No  special  firewall  modifications  are  necessary  for  SIPRNET  deployments. 
The  TEDServices  GateWay  software  components  are  built  around  the  Apache  Web  Server  and  the 
Tomcat  Servlet  Engine.  Since  the  GateWay  supports  bi-directional  communication  through  the  Apache 
Web  Server,  the  machine  on  which  the  GateWay  resides  must  be  connected  and  exposed  to  the  wide-area 
network  in  order  to  allow  service  requests  to  reach  the  Web  Server. 


TEDServices  Technology  Services 

A  TEDServices  GateWay  is  composed  of  several  TEDServices  technology  services.  The  key 
services  of  the  TEDServices  software,  whose  relationships  are  shown  in  Figure  2,  are  the  Local 
DataBroker  (LDB),  GateWay,  Interface  Support,  Local  DataStore  and  Local  VNE.  The  TEDServices 
software  is  Java-based,  providing  for  platform  portability. 


TEDServicesGateWay 


Interface 

i 

ransforms 

GateWay  , 

- m - 

Local  Data 
*  Broker 

^ - 4^ 

Interpolation 


(ZZ  Z^i 

fZ 

Local 

DataStore 

Local 
^VNE _ / 

Fig.  2  -  TEDServices  technology  components  within  a  TEDServices  GateWay 

The  LDB  initiates  and  manages  most  G2G  communications  for  the  bi-directional  flow  of  data 
between  TEDServices  GateWays.  This  communication  management  mitigates  redundant  data  requests 
and  also  cancels  updates  of  unused  data.  The  LDB  is  likewise  responsible  for  writing  and  reading  data  to 
and  from  the  Local  DataStore  and  Local  VNE.  In  addition,  the  LDB  manages  Discrete  Mission  Based 
Data  Requests  (DMBDR)  from  Remote  User  Client  Applications  (RUCA).  A  MetOc  data  order  process 
allows  data  requests  to  be  aligned  with  relevant  mission  specific  packages  and  platforms.  This  reduces 
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the  likelihood  of  requests  for  data  that  are  not  essential  to  a  particular  task.  It  also  offers  a  means  of 
simplifying  training. 

Direct  application  program  interface  (API)  support  is  provided  to  RUCAs  such  as  NITES-II 
OOR,  by  means  of  a  Java  Application  Programmer  Interface  (API).  An  indirect  application  program 
interface  is  delivered  through  the  use  of  a  Data  Ordering  Client  (DOC).  While  the  functionality  of  these 
two  interfaces  remain  essentially  the  same,  the  API  provides  a  direct  program-to-program  interface,  while 
the  DOC  allows  a  loose  coupling  application  strategy  with  physical  file  output  delivered  to  a  user-defined 
data  directory.  DOC  support  was  demonstrated  in  FBE-K  by  PC-Interactive  Multi-sensor  Analysis 
Training  (PC-IMAT). 

The  GateWay  component  manages  communication  aspects  that  are  not  supervised  by  the  LDB, 
such  as  the  wire  portion  of  the  guaranteed  data  delivery  mechanism.  This  component  also  encapsulates 
the  software  that  streamlines  the  process  of  integrating  data  from  heterogeneous  sources  to  a  Common 
Transport  Format  (CTF).  This  CTF  assures  a  uniform  datum,  uniform  projection  and  universal  time 
coordinate.  A  CTF  for  all  data  types  within  TEDServices  simplifies  format  transformations  to  end-users 
and  is  a  significant  factor  for  fostering  interoperability. 

TEDServices  uses  Object-Oriented  cache  software  to  persist  the  Focal  DataStore  and  Focal  VNE 
on  disk.  This  software  provides  transactional  management  and  multi-user  access  to  the  data  and  products 
in  the  DataStore  and  VNE. 


TEDServices  Components  and  the  N096  OpCon 

Each  of  the  N096  OpCon  components  contains  exactly  one  access  point  to  TEDServices.  This 
access  point  is  the  TEDServices  GateWay.  Each  TEDServices  GateWay  is  configured  to  initialize 
specific  parameters  by  area  of  interest  (AOI).  For  FBE-K,  the  parameters  and  AOI  were  known  in 
advance.  Operationally  post-FBE-K,  authorized  users  are  able  to  initialize  parameters  and  AOI  on 
demand. 


TEDServices  Conceptual  Data  Flow 

As  shown  in  Figure  3,  the  GateWay  component  continuously  imports  raw  data  delivered  to  the 
PC  TEDServices  GateWay  and  then  hands  the  data  to  the  LDB  for  storage.  This  raw  data  consists  of 
numerical  weather  and  ocean  prediction  products  such  as  the  Coupled  Ocean/Atmospheric  Mesoscale 
Prediction  System  (COAMPS),  the  Navy’s  Operational  Global  Atmospheric  Prediction  System  Model 
(NOGAPS),  and  the  Modular  Ocean  Data  Assimilation  System  (MODAS).  The  raw  data  is  immediately 
converted  to  Common  Transport  Format  (CTF),  which  is  then  serialized  to  disk  in  the  CTF  DiskStore, 
and  also  placed  in  the  Global  DataStore.  When  data  is  imported  into  the  DataStore  and  CTF  DiskStore, 
the  PC  is  then  ready  to  receive  Data  Requests  (subscriptions)  from  Domain  Authorities  (TEDServices 
GateWays). 

The  DA’s  Init  Data  Request  (IDR)  subscribes  the  DA  to  the  Production  Center  for  all  relevant  PC 
parameters  with  worldwide  or  limited,  specific  coverage.  After  fulfilling  the  IDR,  the  PC  pushes  new 
data  to  the  DA  GateWay  as  new  data  becomes  available.  The  PC  continues  to  push  to  the  DA  until  the 
subscription  is  cancelled.  This  pre-stages  data  at  the  DA  for  the  DA  VNE  process.  This  is  illustrated  in 
Figure  3. 
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Fig.  3  -  PC  to  DA  data  push 


The  CoE’s  IDR  accomplishes  a  similar  subscription.  After  the  DA  LDB  fulfills  the  CoE’s  IDR, 
the  DA  LDB  pushes  new  data  to  the  CoE  as  new  data  becomes  available.  Data  is  pushed  from  the  DA  as 
forecast  event  times  (taus)  are  completed.  This  is  demonstrated  in  Figure  4. 


Fig.  4  -  DA  data  push  to  CoE 
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The  RU  similarly  places  an  IDR  with  the  DA  and  CoE.  After  the  DA/CoE  LDB  fulfills  the  RU’s 
IDR,  the  DA  and  CoE  LDBs  push  new  data  to  the  RU  when  new  data  becomes  available.  This  is 
represented  in  Figure  5. 
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Fig.  5  -  Data  push  to  the  Remote  User  GateWay 


Warner  et  al 


The  end-to-end  data  conceptual  data  flow  for  FBE-K  is  depicted  in  Figure  6. 


Fig.  6  -  End-to-end  data  flow 


TEDSERVICES  AND  FLEET  BATTLE  EXPERIMENT-KILO 
TEDServices  FBE-K  Execution  Objectives 

TEDServices  had  a  number  of  improvement  objectives  inherent  in  its  design.  Among  these  were 
to  simplify  the  data  and  product  ordering  process,  to  automate  the  data  and  product  delivery  process,  to 
reduce  bandwidth  usage,  and  to  achieve  minimum- effort  data  management  and  reliable  transport  systems. 
These  aims  were  reached  through  the  implementation  of  the  Common  Transport  Format  (CTF)  described 
previously,  implementation  of  a  dynamic  packet  compression  (LPAC),  and  development  of  Resumable 
Object  Streams  (ROS).  The  CTF  enables  movement  of  relevant  data  bi-directionally  between  PCs,  DAs, 
CoEs  and  the  RU.  The  common  format  makes  LPAC  feasible.  ROS  allows  the  resumption  of  a  broken 
G2G  communication  session  (not  FTP)  at  the  byte  level  and  was  developed  by  NRL-SSC  (Code  7440). 

Data  management  was  yet  another  goal  for  improvement  of  TEDServices.  The  intent  here  was  to 
simplify  data  ordering  and  provide  the  MetOc  answer  locally.  This  objective  was  achieved  through  the 
LDB,  which  operated  to  mitigate  multiple  “reach-back”  data  requests  for  the  same  parameter/product. 
The  LDB  assured  that  data  relevant  to  specific  missions  was  ordered  for  delivery. 
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Table  1  summarizes  the  TEDServices  execution  objectives  for  each  of  the  TEDServices 
technologies  executed  in  FBE-K.  Appropriate  data  was  collected  during  the  execution  of  FBE-K,  which 
enabled  performance  measurements  to  be  made. 


Table  1  -  TEDServices  Execution  Objectives 


Technology 

Assessment  Metric 

LPAC 

Compare  data  sizes  to  other  favored  compression  schemes. 

ROS 

Measure  savings  in  transmissions  sizes  in  broken 
communications  sessions. 

CASP 

Demonstrate  seamless  exchange  of  application  state 
through  stream  serialized  Java  objects. 

Specific  Consumer  Applications 

The  data  consumers  (TDAs/Applications)  served  by  TEDServices  during  FBE-K  are  shown  in 
Table  2  below.  NITES-II  OOR  and  JMV  were  serviced  through  the  TEDServices  Java  APE  PC-IMAT 
was  served  through  the  TEDServices  Data  Ordering  Client. 

Also  note  that  TEDServices  transformed  NPMOC-Yoko  JMV  generated  Ordnance  Employment 
Fields  (OEF)  depictions  into  SHAPE  files.  These  SHAPE  files  were  transported  to  the  USS  Blue  Ridge 
for  incoiporation  into  the  Area  Air  Defense  Commander  System  (AADCS).  This  was  the  first  time  that 
MetOc  products  had  been  introduced  into  AADCS. 

For  more  details  on  the  OEF  program,  please  refer  to  the  NPMOC  Yokosuka  -  TANDEM 
THRUST  03,  Fleet  Battle  Experiment-Kilo  Post-Exercise  Report. 


Table  2  -  Consumer  Applications  Served  Data  by  TEDServices 


Consumers 

COAMPS 

NOGAPS 

MODAS 

NCOM 

CASP 

OEF 

NITES-  II  OOR 

X 

X 

X 

X 

PC-IMAT 

X 

X 

JMV 

X 

JMV  /  AADCS 

X 

TEDServices  Deployment  in  FBE-K 

Presented  in  Figure  7  are  the  participants  in  FBE-K,  categorized  by  the  conceptual  component 
they  represent  in  the  N096  OpCon.  On  the  SIPRNET,  each  of  the  Production  Centers,  Domain 
Authorities,  Centers  of  Expertise  and  Remote  Users  housed  a  TEDServices  GateWay.  In  Figure  7, 
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bulleted  text  is  used  to  indicate  applications  that  used  TEDServices  during  FBE-K  and/or  products  that 
were  created  using  TEDServices  data. 

Applications  that  used  TEDServices  included  Joint  MetOc  Viewer  (JMV),  NITES-II  OOR,  PC- 
IMAT  via  the  TEDServices  Data  Ordering  Client  and  OASES  via  the  TEDServices  Data  Browser.  The 
USS  Blue  Ridge  was  originally  planned  to  house  a  TEDServices  GateWay  during  the  demonstration; 
however,  the  GateWay  at  the  Fleet  MetOc  Advanced  Concepts  Lab  (FMACL)  in  San  Diego  acted  in 
place  of  the  Blue  Ridge. 


Production  Domain 

Centers  Authority 


Centers  of 
Expertise 


Remote  Client 

Users  Applications 


FNMOC 

NRL- 

MRY 

NAVO 

NAVO 

Yoko 

CVIN 

•JMV 

•JMV 

•  OEF  CASP 

•  OEF  CASP 

•  N200R  Strike 

•  N2-CASP 

Pearl 

•  N200R  ASW 

•  N2-CASP 

•  MODAS/L 


NWDC 
•  Oases 


NRL- 

SSC 


FMACL 


NUWC/ 

Anteon 


Guam 

•  N200R  Strike 

•  N2-CASP 


CVIN 

•PC-IMAT 

CTF-74 

•PC-IMAT 


NWDC 

•PC-IMAT 


Fig.  7  -  TEDServices  GateWay  and  software  deployment  for  FBE-K 


TEDServices  -  Collaborative  Application  Sharing  Process  (CASP) 

To  support  a  distributed,  collaborative  process,  TEDServices  demonstrated  the  use  of  a  unique 
feature  called  the  Collaborative  Application  Sharing  Process  (CASP).  While  CASP  is  an  inherent  feature 
of  TEDServices,  it  is  an  outgrowth  of  the  legacy  SIIP/NITES-II  Product  Generation  and  Transmission 
(PG&T)  capability.  CASP  enables  application  users  to  share  the  “status/state”  of  their  applications 
between  subscribing  consumers. 

CASP  was  demonstrated  by  NPMOC-Yoko  (Figure  8),  and  NITES-II  OOR  (Figure  9). 

NPMOC  Yoko  used  CASP  to  transport  OEF  objects  between  the  Center  and  the  USS  Carl 
Vinson.  The  Center  would  produce  an  initial  forecast  depiction  (12-36  hours),  and  the  USS  Vinson 
would  collaborate  with  a  local  0-12  hour  forecast.  This  process  continued  throughout  FBE-K. 

As  represented  in  Figure  9,  CASP  was  tested  using  the  NITES-II  OOR  application  at  GUAM  and 
PEARL.  The  application  state  of  NITES-II  OOR  at  PEARL  and  GUAM  were  shared  using  CASP.  These 
CASP  objects  were  created  using  atmospheric  and  oceanographic  data  available  in  the  forward  deployed 
cache  on  the  local  TEDServices  Gateways. 
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Production  Domain 

Centers  Authority 


FNMOC 

NRL- 

MRY 

NAVO 

NAVO 

Centers  of  Remote  Client 

Expertise  Users  Applications 


Yoko 

CVIN 

•JMV 

•JMV 

•  OEF  CASP 

•  OEF  CASP 

•  N200R  Strike 

•  N2-CASP 

Pearl 

•  N200R  ASW 

•  N2-CASP 

•  MODAS/L 


NWDC 
•  Oases 


NRL- 

ssc 


FMACL 


NUWC/ 

Anteon 


Guam 

■  N200R  Strike 
•  N2-CASP 


CVIN 

•PC-IMAT 

CTF-74 

•PC-IMAT 


NWDC 

•PC-IMAT 


Fig.  8  -  Ordnance  employment  bi-directional  product  flow  using  CASP 
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NAVO 


Domain 

Authority 


Centers  of 
Expertise 


Remote 

Users 


CVIN 

•  JMV 

•  OEF  CASP 

•  N200R  Strike 

•  N2-CASP 


Client 

Applications 


NWDC 
•  Oases 


CVIN 

•PC-IMAT 

CTF-74 

•PC-IMAT 


NWDC 

•PC-IMAT 


Fig.  9  -  NITES-II  Collaborative  Application  Sharing  Process  flow 
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TEDServices  Data  Browser 

Figure  10  shows  how  NWDC  used  the  TEDServices  Data  Browser  to  extract  the  data  from 
several  TEDServices  GateWays.  This  data  was  then  passed  to  Ocean,  Atmosphere,  Space,  Environmental 
Services  (OASES)  for  distribution  to  a  Modeling  &  Simulation  federation. 


Production  Domain  Centers  of  TEDServices 

Centers  Authority  Expertise  Data  Browser 


COAMPS  &  NOGAPS 
MODAS  &  NCOM 


Fig.  10  -  OASES  support 


Planned  Topology 

Figure  1 1  below  illustrates  the  planned,  automated  oceanographic  data  flow  during  FBE-K.  The 
Fleet  MetOc  Advanced  Concepts  Lab  (FMACL)  was  used  to  simulate  a  TEDServices  GateWay  that 
would  have  been  deployed  aboard  the  USS  Blue  Ridge.  Details  of  the  diagram  follow. 

Within  the  NAVO  SIPRNET,  NCOM  and  MODAS  data  were  FTP’d  to  the  NAVO  TEDServices 
GateWay  machine,  where  it  was  automatically  ingested  into  the  VNE.  Data  for  specific  parameters  were 
then  pushed  to  other  TEDServices  GateWays  (Pearl  Flarbor)  based  on  data  subscriptions  for  particular 
parameters  and  areas  of  interest.  Upon  receipt  of  the  data  at  the  Pearl  Flarbor  TEDServices  GateWay, 
staff  at  Pearl  used  the  parameters  as  first  guess  fields,  along  with  Expendable  Bathythermographs  (XBTs), 
to  run  the  MODAS  LITE  model.  The  value-added  data  was  then  pushed  to  other  TEDServices  GateWays 
(Carl  Vinson,  FMACL,  GUAM  and  NUWC)  based  on  their  data  subscriptions  for  particular  parameters 
and  areas  of  interest. 

Several  Remote  User  Client  Applications  accessed  the  data  on  the  TEDServices  GateWays. 
These  client  applications  included  NITES  II  OOR,  PC-IMAT  Data  Ordering  Client  and  the  TEDServices 
Data  Browser. 
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Production  Domain 

Centers  Authority 


Centers  of 
Expertise 


Remote  Client 

Users  Applications 


Fig.  1 1  -  Planned  MODAS  and  NCOM  model  data  distribution 


Adjusted  Topology 

During  the  second  day  of  FBE-K  there  was  a  critical  hardware  failure  of  the  GateWay  machine  in 
Pearl  Harbor.  Data  flow  was  immediately  redirected  to  other  TEDServices  GateWays  while  a 
replacement  machine  was  routed  to  Pearl.  This  redirect  lasted  approximately  a  day  and  a  half.  The  NRL- 
SSC  core  TEDServices  development  team  provided  remote  support  for  this  redirection  of  TEDServices 
GateWays.  The  redirected  data  flow  is  illustrated  in  the  Figure  12.  In  the  future,  redirection  will  be 
automatic  with  the  selection  of  up  to  three  (3)  sources  for  data. 
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Production  Domain  Centers  of  Remote  Client 

Centers  Authority  Expertise  Users  Applications 


Fig.  12  -  Adjusted  MOD  AS  and  NCOM  model  data  distribution  mid  FBE-K  due  to 
hardware  failure  at  Pearl  Flarbor 


TEDSERVICES  METRICS  DURING  FLEET  BATTLE  EXPERIMENT-KILO 

This  section  provides  performance  metrics  specific  to  the  deployment  of  TEDServices  Gateways 
and  software  in  FBE-K.  The  following  metrics  trace  MODAS  and  NCOM  model  data  in  an  end-to-end 
data  flow  that  occurred  during  FBE-K. 


NAVO  Ingest  Metrics 

All  data  ingested  at  Production  Centers  occurred  in  an  automated  fashion.  Using  scripts,  chron 
jobs  or  scheduled  services,  data  was  FTP’d  to  the  TEDServices  GateWay  where  it  was  automatically 
ingested.  No  human  interaction  was  required  for  the  ingest  process  to  occur.  An  ingest  process  was 
continually  running  in  the  background  on  the  TEDServices  GateWay.  The  process  ingested  data  files  that 
it  found  and  then  slept  for  a  configurable  amount  of  time.  The  process  then  awoke  and  looked  for  any 
new  files  to  process.  This  describes  the  basic  ingest  loop  that  automated  the  model  data  ingest. 

Table  3  describes  the  amount  of  oceanographic  model  data  ingested  at  the  NAVO  TEDServices 
GateWay  during  FBE-K  and  the  resulting  size  of  the  compressed,  stored  data. 
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Table  3  -  Size  of  Ingested  and  Stored  Model  Data  at  NAVO  TEDServices  GateWay 


Daily  Model  Data 

Cumulative  Model 

Model  Data 
Ingested 

Received  at  NAVO 
TEDServices 

GateWay  (approx.) 

Data  Received  at 

NAVO  TEDServices 
GateWay  (approx.) 

Cumulative  NAVO 
TEDServices  GateWay 
VNE  Size  (approx.) 

MODAS 

31.91  MB 

255.26  MB 

91.20  MB 

NCOM 

369.91  MB 

2,959.25  MB 

1160.00  MB 

Totals 

401.82  MB 

3,214.51  MB 

1,251.20  MB 

MODAS  Data 

MODAS  data  was  FTP'd  to  the  NAVO  TEDServices  GateWay  once  per  day  for  the  length  of 
FBE-K  (eight  days).  The  model  data  contained  three  parameters  (salinity,  sound  speed  and  sea 
temperature)  and  covered  an  area  of  interest  specified  by  the  following  bounding  box: 

South  Latitude:  7.0 
West  Longitude:  133.0 
North  Latitude:  30.0 
East  Longitude:  157.0 

The  amount  of  raw  data  FTP'd  per  day  is  listed  in  Table  3  in  the  column  titled  “Daily  Model  Data 
Received  at  NAVO  TEDServices  GateWay.”  Per  day,  the  raw  model  data  totaled  32  MB.  The  amount  of 
MODAS  data  ingested  at  the  NAVO  TEDServices  GateWay  during  FBE-K  totaled  255  MB.  The  ingest 
of  MODAS  raw  data  contributed  11.4  MB  to  the  VNE  on  a  daily  basis  resulting  in  a  VNE  that  totaled  of 
91  MB  at  the  completion  of  FBE-K.  The  shrinkage  of  the  ingested  data  from  255MB  to  91  MB  can  be 
attributed  to  the  LPAC  compression  utilized. 


NCOM  Data 


NAVO  produced  NCOM  data  was  FTP'd  to  the  NAVO  TEDServices  GateWay  once  per  day  for 
the  length  of  FBE-K.  The  model  data  contained  six  parameters  (salinity,  sound  speed,  sea  temperature, 
water  level  elevation,  u  component  and  v  component)  and  covered  the  same  area  of  interest  listed  for  the 
MODAS  data. 

The  amount  of  NCOM  raw  data  FTP'd  per  day  is  listed  in  Table  3  in  the  column  titled  “Daily 
Model  Data  Received  at  NAVO  TEDServices  GateWay.”  Per  day,  the  raw  model  data  totaled  ~370  MB. 
The  amount  of  NCOM  data  ingested  at  the  NAVO  TEDServices  GateWay  during  FBE-K  totaled  almost  3 
GB.  The  ingest  of  NCOM  raw  data,  contributed  145  MB  to  the  VNE  on  a  daily  basis  resulting  in  a  VNE 
that  totaled  slightly  over  1  GB  at  the  completion  of  FBE-K.  The  shrinkage  of  the  ingested  data  from  3 
GB  to  1  GB  can  be  attributed  to  the  LPAC  compression  utilized. 
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NAVO  Transmission  Details 

Originally,  per  the  FBE-K  topology,  NAVO  was  scheduled  to  transmit  data  only  to  Pearl  Harbor 
and  NRL-SSC.  Pearl,  acting  as  a  Domain  Authority,  would  then  transmit  data  to  Yoko,  NUWC, 
FMACL,  CVIN  and  GUAM  based  on  their  subscriptions.  However,  due  to  a  catastrophic  hardware  failure 
at  PEARL  on  the  5th  day  of  FBE-K,  data  subscriptions  for  Yoko,  NUWC,  FMACL,  CVIN  and  GUAM 
were  rerouted  directly  to  NAVO  for  approximately  a  day  and  a  half. 

The  equipment  failure  at  Pearl  was  rectified  on  the  second  to  last  day  of  FBE-K.  The  data 
subscriptions  for  Yoko,  NUWC,  FMACL,  CVIN  and  GUAM  were  cancelled  at  NAVO  and  re-established 
at  PEARL. 

Table  4  describes  which  GateWays  were  subscribed  to  receive  oceanographic  model  data  from 
the  NAVO  TEDServices  GateWay  and  how  the  NAVO  TEDServices  GateWay  data  transmissions  were 
distributed  among  the  subscribing  parties  (NRL-SSC,  Pearl  Harbor,  Yoko,  NUWC,  FMACL,  CVIN  and 
GUAM  TEDServices  GateWays). 


Table  4  -  Transmissions  From  the  NAVO  TEDServices  GateWay  to  Other  TEDServices  GateWays 


Receiving  TEDServices  GateWay 

Amount  Received 

Pearl  Harbor 

554.69  MB 

NRL-SSC 

214.10  MB 

YOKO 

29.05  MB 

NUWC 

19.88  MB 

FMACL 

17.72  MB 

CVIN 

12.40  MB 

GUAM 

4.30  MB 

NAVO  Total  Transmissions 

852.14  MB 

The  TEDServices  GateWays  located  at  YOKO,  NUWC,  FMACL,  CVIN  and  GUAM  were 
subscribed  to  the  NAVO  TEDServices  GateWay  for  approximately  two  days  and  for  smaller  Areas  of 
Interest  (AOI)  than  Pearl  Harbor  and  NRL-SSC.  The  amount  of  data  to  be  transmitted  to  the  YOKO, 
NUWC,  FMACL,  CVIN  GateWays  was  much  less  than  what  was  to  be  transmitted  to  Pearl  Harbor  and 
NRL-SSC.  However,  NAVO  should  have  successfully  transmitted  the  same  amount  of  data  to  each  of 
the  YOKO,  NUWC,  FMACL,  CVIN  GateWays  as  they  were  subscribed  to  the  same  smaller  AOI  for  the 
same  parameters.  The  amount  of  oceanographic  data  that  NAVO  should  have  successfully  transmitted  to 
each  of  these  Gateways  over  the  two-day  period  was  approximately  29.05  MB,  the  amount  that  Yoko 
received.  Network  connectivity  issues  that  lasted  for  extended  periods  of  time  prevented  this  from 
happening. 


Resumable  Object  Streams  (ROS) 

A  delivery  guarantee  mechanism  was  implemented  in  TEDServices  and  used  during  FBE-K. 
This  delivery  mechanism  is  Resumable  Object  Streams  (ROS).  ROS  is  a  mechanism  that  guarantees 
delivery  of  transmission  data  within  a  specified  maximum  try  time  interval.  That  is,  ROS  will  continue 
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attempting  to  deliver  transmission  data  for  the  time  interval  specified.  If  the  transmission  data  cannot  be 
delivered  within  the  specified  time,  the  transmission  is  then  dropped.  During  FBE-K,  ROS  was 
configured  so  that  it  would  try  to  complete  a  transmission  for  up  to  two  hours.  According  to  these 
numbers,  that  was  not  long  enough. 

FBE-K  drove  home  the  point  that  network  centric  warfare  is  not  a  perfect  world.  Loss  of  network 
connectivity  for  extended  periods  of  time  must  be  considered.  In  the  course  of  FBE-K,  the  following 
incidents  occurred  that  affected  connectivity  for  intervals  of  more  than  two  hours  at  time.  Each  of  these 
incidents  occurred  in  different  locations. 

•  On  an  afloat  platform,  the  local  SIPRNET  went  down. 

•  A  network  cable  was  unplugged  from  a  TEDServices  GateWay  in  order  to  share  with  another 

machine. 

•  A  cleaning  crew  accidentally  turned  off  the  power  to  a  TEDServices  GateWay. 

•  A  catastrophic  hardware  failure  occurred  on  one  of  the  TEDServices  GateWays. 

This  exercise  highlighted  that  particular  attention  must  be  paid  to  development  for  an  automated 
system.  ROS  was  sufficient  for  a  window  of  opportunity  -  if  the  network  went  down  or  the  receiving 
server  went  down,  ROS  guaranteed  delivery  within  a  two  hour  window. 

After  the  configurable  retry  limit  was  exceeded,  ROS  timed  out  and  dropped  the  transmission. 
Something  more  was  needed  in  addition  to  this  retry  interval.  The  exercise  helped  in  identifying  a  weak 
point  in  the  delivery  process.  This  has  been  fixed  within  the  TEDServices  Local  Data  Broker.  After  a 
timeout,  the  LDB  puts  data  to  be  sent  to  the  remote  gateway  into  a  queue  and  periodically  monitors  the 
network  for  restored  connectivity.  The  transmitting  GateWay  will  resume  transmission  of  data  (using 
ROS)  once  the  receiving  GateWay  comes  back  on-line.  In  the  latter  case,  only  the  most  current  data  is 
sent. 


The  version  of  ROS  used  in  FBE-K  worked  well  for  network  hiccups  and  network  outages  that 
were  shorter  than  two  hours.  During  FBE-K,  eight  cases  were  recorded  where  network  connectivity  was 
lost  in  mid  data  transmit.  When  network  connectivity  was  regained,  ROS  continued  the  data  transmission 
at  the  point  where  it  was  interrupted.  It  did  not  retransmit  the  entire  data  transmission,  only  the  portion  of 
the  data  that  was  not  transmitted  initially.  In  other  cases,  ROS  guaranteed  delivery  by  establishing  initial 
connectivity  prior  to  sending  data  as  the  remote  TEDServices  GateWay  was  unreachable  upon  initial 
attempt  to  transmit  data. 


NAVO  Transmission  Details 

In  Table  4,  the  Pearl  Harbor  TEDServices  GateWay  is  listed  as  receiving  data  from  the  NAVO 
TEDServices  GateWay.  Pearl  Harbor  received  NCOM  and  MODAS  data  for  six  days  instead  of  eight 
due  to  the  hardware  failure  at  Pearl  Harbor.  The  numbers  reflected  for  Pearl  Harbor  in  the  above  table 
indicate  that  all  appropriate  data  was  transmitted  from  NAVO  and  received  by  Pearl  Harbor.  NRL-SSC  is 
also  listed  in  the  above  table  as  receiving  data  from  NAVO.  However  NRL-SSC  received  data  from 
NAVO  for  only  two  days,  from  the  time  of  the  hardware  failure  at  Pearl  through  the  end  of  FBE-K. 

Figure  13  is  a  scatter  plot  that  compares  the  sizes  of  the  NAVO  TEDServices  GateWay 
transmissions  and  amount  of  time  required  to  successfully  transmit  the  data.  This  plot  includes 
transmissions  of  oceanographic  data  for  a  total  711  transmissions.  While  some  of  the  transmit  time 
variations  can  be  attributed  to  network  latencies,  it  is  reasonable  to  suggest  that  the  transmissions  in  the 
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plot  that  required  longer  than  2.5  minutes  to  transmit  are  the  cases  where  ROS  was  guaranteeing  the 
delivery  of  data  within  a  specified  maximum  try  time  interval.  That  is  ROS  continued  attempting  to 
deliver  transmission  data  for  the  time  interval  specified  and  encountered  network  connectivity  issues. 
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Fig.  13  -  NAVO  TEDServices  GateWay  transmissions 


There  were  forty-two  transmissions  that  took  longer  than  2.5  minutes  to  successfully  transmit. 
Note  in  particular  the  transmission  on  the  upper  left  of  the  graph.  The  transmission  was  about  500  KB 
and  took  ten  minutes  to  guarantee  delivery.  This  transmission  would  most  likely  have  been  dropped 
without  ROS. 

ROS  is  a  built-in  feature  of  all  GateWay-to-GateWay  transmissions.  Therefore,  ROS  was  utilized 
in  each  successful  transmission.  The  amount  of  ROS  assistance  provided  was  dependent  upon  the 
connectivity  issue  encountered.  If  no  connectivity  issue  was  encountered,  then  minimal  ROS  assistance 
was  provided. 

Of  the  G2G  transmissions  where  ROS  guaranteed  delivery,  most  required  that  ROS  assist  in 
establishing  initial  connectivity  prior  to  sending  data  as  the  remote  TEDServices  GateWay  was 
unreachable  upon  initial  attempt  to  transmit  data.  Some  of  the  G2G  transmissions  lost  connectivity  in 
mid  data  transmit.  In  those  cases,  ROS  regained  connectivity  and  transmitted  the  remainder  of  the  data  to 
the  remote  TEDServices  GateWay.  There  were  eight  of  these  incidents  during  FBE-K.  In  the  case  of 
NAVO  NCOM  data,  the  transmission  could  have  been  as  large  as  6.6  MB.  Whether  there  was  no  initial 
connectivity  or  whether  connectivity  was  lost  in  the  course  of  transmission,  without  ROS,  the 
transmissions  would  have  been  dropped. 


TEDServices  Post-FBE-K  Technical  Execution  Report 


19 


Pearl  Harbor  Transmission  Details 

Upon  receipt  of  the  oceanographic  data  from  the  NAVO  TEDServices  GateWay,  staff  at  Pearl 
Harbor  used  parameters  obtained  from  the  local  TEDServices  GateWay  as  first  guess  fields  when  running 
the  MODAS  LITE  model.  The  value-added  data  was  then  pushed  to  other  TEDServices  GateWays  (Carl 
Vinson,  FMACL,  GUAM  and  NUWC)  based  on  their  data  subscriptions  for  particular  parameters  and 
areas  of  interest. 

Table  5  describes  how  the  Pearl  Harbor  TEDServices  GateWay  transmissions  were  distributed 
among  Yoko,  NUWC,  FMACL,  CVIN  and  GUAM  TEDServices  GateWays.  This  table  includes 
oceanographic  and  atmospheric  data  transmissions. 


Table  5  -  Transmissions  From  the  Pearl  Harbor  TEDServices 
GateWay  to  Other  TEDServices  GateWays 


Receiving  TEDServices  GateWay 

Amount 

Received 

NRL-SSC 

466.2  MB 

GUAM 

53.5  MB 

NUWC 

50.6  MB 

FMACL 

48.9  MB 

CVIN 

28.9  MB 

YOKO 

11.35  MB 

Pearl  Harbor  Total  Transmissions 

659.45  MB 

As  the  Pearl  Harbor  TEDServices  GateWay  had  a  hardware  failure  that  lasted  two  days,  the 
numbers  above  reflect  approximately  5  to  6  days  worth  of  data  transmissions  from  Pearl  Harbor 
TEDServices  GateWay  to  other  TEDServices  GateWays.  The  amount  of  data  transmitted  to  NRL-SSC 
was  much  larger  than  the  amount  of  data  transmitted  to  the  other  GateWays.  This  is  because  NRL-SSC 
was  subscribed  to  a  larger  AOI  than  the  other  TEDServices  GateWays. 

The  above  numbers  seem  to  indicate  that  by  allowing  subscriptions  for  different  subsets  of 
available  data,  bandwidth  is  better  utilized  by  transmitting  only  the  required  data.  However,  because 
there  were  dropped  transmissions  as  mentioned  in  the  previous  section,  it  is  more  accurate  to  illustrate  the 
amount  of  savings  using  a  controlled  environment.  This  will  be  done  in  the  upcoming  section  titled 
“Pipeline  Management.” 

Figure  14  is  a  scatter  plot  that  compares  the  sizes  of  the  Pearl  Harbor  TEDServices  GateWay 
transmissions  and  amount  of  time  required  to  successfully  transmit  the  data.  This  plot  includes 
transmissions  of  oceanographic  and  atmospheric  data  for  a  total  5463  transmissions.  On  the  left  side  of 
the  plot,  note  that  there  are  some  small  transmissions  that  took  just  over  20  minutes.  While  some  of  the 
transmit  time  variations  can  be  attributed  to  network  latencies,  it  is  reasonable  to  suggest  transmissions 
taking  more  than  2.5  minutes  are  the  transmissions  where  ROS  assistance  was  required  in  order  for  the 
data  to  be  delivered.  Note  the  many  1  KB  transmissions  that  required  ten  minutes  or  more.  ROS 
continued  attempting  to  deliver  transmission  data  for  the  time  interval  specified  and  encountered  network 
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connectivity  issues.  Within  the  10-25  minutes,  ROS  was  able  to  gain  initial  connectivity  or  regain 
broken  connectivity  to  deliver  the  data. 
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Fig.  14  -  Pearl  Flarbor  TEDServices  GateWay  to  GateWay  transmissions 

Pipeline  Management 


TEDServices  managed  the  amount  of  data  passed  through  the  SIPRNET  communications  “pipe” 
by  several  methods.  LPAC  compressed  the  data  prior  to  transmitting  it  and  ROS  mitigated  the  need  to 
resend  data  through  the  pipe.  In  addition,  the  TEDServices  architecture  and  implementation  gave  the 
ability  to  trim  data  as  it  traveled  across  the  pipeline  from  the  Production  Center  to  the  Warfighter.  This 
reduction  of  data  was  accomplished  using  a  phased  pipeline  management  approach.  This  phased 
approach  allowed  data  that  traveled  across  the  pipe  to  be  trimmed  at  two  key  points  as  illustrated  in 
Figure  15. 


At  point  A,  trimmed  data  by 
transmitting  only  3  of  6  available 
NCOM  parameters. 


At  point  B,  trimmed  data  by 
transmitting  only  a  subset  of  the 
AOI  housed  at  Pearl. 


Fig.  15  -  Phased  reduction  of  data  transmissions 
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NAVO  ingested  three  MODAS  parameters  and  six  NCOM  parameters.  Pearl  Harbor  subscribed 
to  all  three  MODAS  parameters,  but  only  three  of  the  six  NCOM  parameters.  The  six  NCOM  parameters 
that  were  available  included: 

•  salinity 

•  sound  velocity 

•  sea  temperature 

•  water  level  elevation 

•  v  component 

•  u  component 

The  three  parameters  that  were  subscribed  to  included: 

•  salinity 

•  sound  velocity 

•  sea  temperature 

One  run  of  NCOM  data,  which  contained  the  six  parameters,  would  have  produced  transmissions 
from  NAVO  to  Pearl  Harbor  that  totaled  145  MB  in  size.  Instead,  by  allowing  only  the  needed 
parameters  to  be  transmitted,  the  NCOM  transmissions  totaled  only  87  MB  in  size. 

This  represents  bandwidth  savings  at  point  A.  Note  that  savings  is  “per  run”  of  the  NCOM 
model.  As  a  by  product,  this  allowed  for  a  smaller  amount  of  data  to  be  stored  at  the  Pearl  Harbor 
TEDServices  GateWay.  Notice  how  the  data  stores  shrink  in  size  from  left  to  right  in  Figure  15. 

Pearl  Harbor  subscribed  to  and  received  three  NCOM  parameters  from  NAVO.  The  Carl  Vinson 
and  GUAM  subscribed  to  Pearl  Harbor  for  all  three  available  NCOM  parameters  but  for  a  smaller  area  of 
interest  than  what  was  available  on  the  Pearl  Harbor  TEDServices  GateWay. 

The  area  available  included: 

South  Latitude:  7.0 
West  Longitude:  133.0 
North  Latitude:  30.0 
East  Longitude:  157.0 

The  area  subscribed  to  included: 

South  Latitude:  11.0 
West  Longitude:  143.0 
North  Latitude:  17.0 
East  Longitude:  151.0 

Transmissions  from  the  Pearl  Harbor  TEDServices  GateWay  to  the  GUAM  or  CVIN 
TEDServices  GateWay  would  have  totaled  87  MB  in  size  with  the  total  available  AOI.  Instead,  by 
allowing  only  the  needed  AOI  to  be  transmitted,  the  NCOM  transmissions  totaled  only  7.7  MB  in  size. 
This  represents  bandwidth  savings  at  point  B.  This  also  is  a  “per  model  run”  savings. 
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During  FBE-K,  the  data  trimming  occurred  by  parameter  at  point  A  and  by  AOI  at  point  B; 
however,  trimming  by  parameter  or  by  AOI  can  occur  at  either  location  and  it  can  occur  simultaneously  at 
a  single  location.  Simultaneous  trimming  would  result  in  maximum  savings  of  bandwidth  usage. 

The  numbers  presented  above  are  the  most  accurate  way  to  represent  the  pipeline  management. 
Actual  numbers  from  FBE-K  would  not  present  data  from  which  inferences  could  be  made.  This  is  due  to 
hardware  failures  and  other  circumstances  beyond  control  which  were  previously  described.  The  above 
numbers  were  obtained  by  capturing  the  raw  NCOM  model  data  from  one  day  during  FBE-K,  then 
running  the  subscription/transmission  process  in  a  controlled  environment. 


Client  Applications 

The  TEDServices  GateWays  at  FMACL,  CVIN  and  GUAM  did  not  have  any  clients  in  the  form 
of  TEDServices  GateWays;  therefore,  no  G2G  transmission  details  were  available  to  capture.  These 
GateWays  had  clients  in  the  form  TDAs  as  suggested  in  Figure  11. 

For  example,  the  NITES  II  OOR  TDA  was  utilized  to  access  the  oceanographic  data  that  was 
received  on  the  local  TEDServices  GateWay  at  GUAM  and  CVIN.  In  addition,  data  was  obtained  from 
the  FMACL  TEDServices  GateWay  for  the  PC-IMAT  client  application  via  the  TEDServices  Data 
Ordering  Client.  The  latter  is  a  Java-based  GUI  providing  support  to  legacy  systems.  OASES  used  the 
TEDServices  Data  Browser  to  obtain  oceanographic  data  from  the  Pearl  Harbor  TEDServices  GateWay 
and  atmospheric  data  from  NRL  MRY.  OASES  extracted  the  data  in  netCDF  file  format.  After  the  Pearl 
Harbor  hardware  failure,  OASES  was  redirected  to  the  NAVO  TEDServices  GateWay. 


SUMMARY 

During  FBE-K,  TEDServices  successfully  demonstrated  a  number  of  capabilities.  One  was  to 
reduce  the  number  and  size  of  data  transmissions.  This  capability  was  made  possible  via  publish-and- 
subscribe  mechanisms,  the  use  of  LPAC  to  compress  data  transmissions  and  the  implementation  of 
Resumable  Object  Streams.  A  phased  pipeline  management  approach  minimized  movement  of 
unnecessary  parameters  to  GateWay  locations.  Also  demonstrated  was  the  automated  end-to-end  data 
flow,  which  reduced  the  amount  of  time  spent  acquiring  data  by  the  staff  at  PC,  DA,  COE  and  Remote 
User  locations.  The  seamless  exchange  of  application  state  through  stream  serialized  Java  objects,  made 
possible  in  the  form  of  CASP,  was  also  demonstrated. 

This  report  outlines  just  a  few  of  the  design  goals  that  were  met.  Overall,  the  FBE-K 
demonstration  of  TEDServices  satisfied  the  original  goals  of  data  transport,  data  management,  data 
representation  and  data  transformation.  TEDServices  successfully  showed  reduction  in  bandwidth  use 
and  forward  deployment  of  the  MetOc  answer  through  simplified  data  ordering.  Data  was  normalized 
under  one  single  geospatial  and  temporal  time  coordinate  reference  model  within  the  CTF.  Multiple  end- 
user  required  formats  were  supported  (SHAPE,  draw,  netCDF,  Java  object).  A  seamless  exporting  of 
operational  data  to  M&S  users  was  accomplished. 
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